An industrial plant or process such as e.g. chemical plants, oil refineries, pulp and paper mills, steel mills etc includes many items or units of “real-world objects”, which in many cases are controlled by a computer based control system. Control systems usually generate alarms when problems, related to these real-world objects, occur in order to alert either the system operator or other personnel involved in servicing the plant or process, so that the problem can be resolved as soon as possible.
Real-world objects in this context means physical entities/units such as sensors, valves, pumps, tanks, motors, conveyors, robots, computers, power supplies, network equipment etc. But a real-world object may also be an abstract entity that represents some physical equipment that is grouped together. Some examples of this type of collected physical equipment are production cells, production lines, production plants etc. A real-world object may also be an abstract entity that represents a software function, such as a calculation or a process model.
FIG. 1 illustrates an example of a typical computer based control system. It consists of controllers, servers and workstations connected to a local area network. Servers are computers that include software that provides various forms of system functionality. Workstations are computers that include software that provides various forms of user interaction. Controllers are computers that include software that performs the actual control functions. To the controllers, sensors and actuators are connected for measuring and affecting various forms of process variables, such as temperature, flow, pressure, level, position, on/off position etc. Variations of this basic structure are of course possible. For example, server and workstation functionality may reside in the same computer, or server and control functionality, or any other combination.
Besides functions for controlling a process, control systems normally also include monitoring or supervisory functions, including functions for generating alarms on various conditions related to the controlled and supervised real-world objects. A monitoring function is typically set to generate an alarm when a monitored object in some sense is outside its normal operating condition/range, for example a flow is too low or a temperature is too high or a level is below the minimum allowed or there is a failure in a power supply or in some network equipment etc.
Other sources of alarms include software applications such as applications for condition monitoring, optimization, calculations etc. A condition monitoring application may for example generate an alarm when a certain piece of equipment is in need of repair or maintenance. An optimisation application may generate an alarm when it is unable to maintain the controlled process within certain predetermined boundary conditions, such as maximum allowed energy consumption or product quality parameters etc. A calculation may for example generate an alarm when the result of a calculation is outside certain predetermined limits.
Control systems normally include software to collect, evaluate, store, and display alarm information. Such software is here referred to as an alarm processing system.
In a large plant there may be very large numbers of such sources of alarms, ranging from hundreds to hundreds of thousands, depending on the size of the plant. In many cases alarms may be generated without any real problem being present. This may for example be the case during start-up or shut down of a plant or a section of a plant, or during a shift from the production of one product or quality to another, or while a section of the plant is being serviced. Alarms generated under these conditions are not only confusing, they steal/occupy the operator's attention from more important information, and they make the operator's work stressful.
Other examples where alarms are not important or relevant are when they are generated because of secondary faults. For example, if a pump fails the corresponding flow and pressure will soon be too low. An alarm on the pump failure is enough to raise the operators attention to the problem, the following or consequential alarms caused by the flow and the pressure being too low are not needed for the operator determining the real cause of the problem.
Traditional ways of dealing with this problem involves suppressing the alarm signals at the alarm source, i.e. functionality is added in the controllers and software applications where alarms are generated, to prevent the alarms from being generated under specific conditions. Besides the fact that it requires programming and can only be done by experts, this approach means that it is not possible to view the suppressed alarms at all, since they are never generated or transferred. Since the suppressing is done through programming, operator oriented documentation and overview of what alarms are suppressed under what conditions must be created and maintained manually, adding to the workload and complexity.
A better approach would be to make the alarm system configurable, such that a process engineer or a skilled operator can decide to temporarily hide alarms from certain objects under certain conditions. In this approach the alarms are still generated and may be stored/saved in the control system, and can later be viewed if necessary, but they are not presented to the operator as long as they are hidden.
WO01/02953 describes a method for integration of many and various types of applications in a computerized system. This method is based on a concept where real world objects are represented as composite. Different facets of a real world object, such as its physical location, the current stage in a process, a control function, an operator interaction etc., are described as different aspects of the composite object. In this application, composite objects as defined by WO01/02953 are referred to as aspect objects.
A feature of the method described in WO01/02953 is that aspect objects can be organized in structures. A structure of aspect objects is a hierarchy of object instances. It may be based on any type of relations between aspect object instances. An aspect object can be placed in several structures at the same time, where the different structures represent different relations, e.g. functional and physical containment (functional structure and location structure).
EP 1442413 describes a method and system for a client application to request a data item from a data source in a computer controlled control system, via an access server. The control system includes software objects and a plurality of access servers. The software objects represent various entities that have a defined functional meaning in the control system. Each access server, such as an OPC (Object linking & embedding for Processor Control) server, may provide access to one or more real-time data, historical data, and alarm and event data items. EP 1442413 describes means, by which information held by said objects is used to find out which access server handles a particular data item and to access the data item, transparently to the client application.
U.S. Pat. No. 5,581,242 describe an automatic alarm display processing system in which derivative alarms are suppressed when a failure arises in a plant. The described system uses table look-up to find a causal relation between an alarm and an event and device monitor information in a table that contains alarm suppression reasons for a plurality of alarms. The table is used to decide whether an alarm is to be displayed without use of any inference function, thus avoiding long processing times.